Data Collection
Setup Guide — Configuring How Data Is Requested and Collected
| Last updated: September 2026
Contents
- Overview
- Key Concept: The Four Building Blocks
- Finding Your Way Around
- Adding a Data Collection
- Request Model
- Manage Templates
- User Groups
- Data Steward
- Putting It Together
- Quick Reference
1. Overview
Data Collection is where you set up how a piece of data can be requested and collected in OnCoor. It's the configuration behind the Material Request and Material Steward screens: everything a requester fills in, every template they can pick, who's allowed to raise a request, and who processes it, is defined here.
You configure data collection one domain object at a time (for example, Material Data or a reference data set). For each object, you set up four things — the Request Model, one or more Templates, the User Groups who can request it, and the Data Stewards who handle it.
What you can do here
- Turn on data collection for a domain object.
- Define the Request Model — the table and fields a request collects.
- Create and manage Templates that shape how data is entered.
- Set up User Groups — who can raise requests, and which templates they may use.
- Add Data Stewards — who processes requests, and who may create system-based ones.
WHERE TO FIND IT — Data Collection lives under Governance → Configuration → Data Collection. It opens on a landing page listing the domain objects that already have data collection configured.
2. Key Concept: The Four Building Blocks
For each domain object, data collection is built from four parts. They work together, and it helps to know what each one does before you start.
| Building block | What it defines |
|---|---|
| Request Model | The foundation — the database table and the set of columns (fields) a request collects. Everything else builds on this. |
| Templates | The forms built on the Request Model — the specific layouts a requester chooses from when raising a request. |
| User Groups | Who is allowed to raise requests for this object, and which templates each group can use. |
| Data Stewards | Who processes the requests, and who is allowed to create system-based requests. |
On the landing page, each configured domain object is shown with four cards — Manage Templates, Request Model, User Groups, and Data Steward — one for each building block. Clicking a card opens that area.
THE REQUEST MODEL COMES FIRST — The Request Model defines the fields everything else relies on, and it has to be activated before the object is ready to use. Set it up first, then build templates, groups, and stewards on top of it.
3. Finding Your Way Around
Go to Governance → Configuration → Data Collection. The landing page shows a short instruction at the top and then, for each domain object that's been configured, a heading — Configure [object name] — followed by its four cards:
- Manage Templates — the templates for this object.
- Request Model — the object's fields and structure.
- User Groups — who can raise requests.
- Data Steward — who processes them.
Click a card to open that area. Every sub-page has a Back To Config link at the top left to return you to this landing page. A floating + button at the bottom right adds a new data collection (covered next).
4. Adding a Data Collection
Before you can configure the four building blocks, the domain object needs data collection switched on.
Steps
- On the landing page, click the floating + button.
- In the Add Data Collection dialog, choose the object from the Select an Object drop-down. (The list shows only objects that don't already have data collection turned on.)
- Click Save & Close.
Data collection is now switched on for that object, and it appears on the landing page with its four cards. If the object is template-based, OnCoor takes you straight to its Request Model so you can start defining its fields.
5. Request Model
The Request Model is the foundation for the object — the table its data lands in and the columns (fields) a request collects. Open it from the Request Model card.
The model's details
At the top of the page are the model's settings:
| Field | What it's for |
|---|---|
| Domain Object | The object this model belongs to (fixed). |
| Schema Name | The database schema the data is stored under. |
| Table Name | The name of the table the data lands in. |
| Conform Data Name | The catalogued data this model maps to. |
| Request Menu Title | Which menu the requester screen appears under. |
| Data Steward Menu Title | Which menu the steward screen appears under. |
| Layout | The screen layout used for the request. The + beside it lets you add a new layout. |
The columns
Below the settings is a table of the model's columns — the individual fields a request collects. Add a column with the add icon in the Action column; remove one with the delete icon. Each column has:
| Column setting | What it means |
|---|---|
| Column Name | The field's name in the table. |
| Column Description | The label a requester sees for the field. |
| Col Data Type | The kind of data the field holds. |
| Col Length / Precision / Scale | The size and numeric detail of the field. |
| Is Primary Key | Whether this field uniquely identifies each entry (Yes/No). |
| Field Display Type | How the field appears on the form — text, number, date, tick-box, or drop-down. |
| Dropdown Sql | For drop-down fields, where the list of choices comes from. |
Activating the model
The model has a status — Open or Active — shown at the top right. While it's Open you can edit the settings and columns. Click Activate to make it live. Activation requires the Schema Name, Table Name, Conform Data Name, Request Menu Title, Data Steward Menu Title, and Layout to all be filled in — if any are missing, OnCoor lists them and won't activate.
ACTIVATION LOCKS THE STRUCTURE — Once a Request Model is Active, its settings become read-only. Get the fields and columns right while it's still Open, because activating fixes the structure that templates and requests depend on.
6. Manage Templates
Templates are the forms built on the Request Model — the specific versions a requester chooses when they raise a request. Open the list from the Manage Templates card; the page is titled Template List.
The template list
Each row is a template. The columns can be edited directly in the table (except status and the created/updated stamps):
| Column | What it shows |
|---|---|
| Template Name | The template's name. |
| Template Table Name | The table the template writes to. |
| Description | What the template is for. |
| Update Type / Type | How the template updates data, and its type. |
| Status | Whether the template is Open or ready to use. |
| Source / Queue | The data source and processing queue it uses. |
| Create Table SQL / Select Request Data SQL | The SQL that builds the table and selects the request data. |
| Created / Updated By and Date | Who changed the template and when. |
Adding a template — click the floating + button and fill in the Add New Template dialog: Template Name (required), Template Type (required), Template Table Name, Description, Source, Queue, and the two SQL fields. New templates start with an Open status.
Editing a template — click the Edit icon on a row to open the template editor, where the template's layout and mapping are set up. (The Mapping Template Property dialog is where a template's queue and update details are adjusted.)
Deleting a template — click the Delete icon and confirm.
7. User Groups
User Groups control who can raise requests for this object, and which templates they may use. Open the list from the User Groups card; the page is titled User Groups.
The group list
Each row is a group, editable in place (except status and stamps):
| Column | What it shows |
|---|---|
| Group Name | The group's name. |
| Group Description | What the group is for. |
| Status | Open or Active. |
| Can Create Request | Whether members of this group may raise requests (tick-box). |
| Created / Updated By and Date | Who changed the group and when. |
Adding a group — click the floating + button and fill in the Add New User Group dialog: Group Name (required), Description, and Can Create Request (Yes/No).
Setting up a group — click the Edit icon to open the group's detail, which has two parts:
- List of Users — the people in the group. Add someone with Add User (choose the User Name and an Action Type), and remove a user with the delete icon. There's also a setting for whether users of this group can submit requests.
- Templates — the templates this group is allowed to use, each shown with its Master Data, Template, and Template Type. Use Add to assign a template to the group, and the remove icon to take one away.
A GROUP TIES USERS TO TEMPLATES — Adding people to a group and assigning templates to that group is what decides which requesters can use which templates. A requester sees a template only if they're in a group that has it.
8. Data Steward
Data Stewards are the people who process the requests for this object. Open the list from the Data Steward card; the page is titled Data Steward.
The steward list
| Column | What it shows |
|---|---|
| User Name | The steward. |
| Can Create System Based Request | Whether this steward may create system-based requests (tick-box) — the setting behind the "Create System Based Request" button in Material Steward. |
| Created / Updated By and Date | Who changed the entry and when. |
Adding a steward — click the floating + button and fill in the Add Data Steward dialog: choose the User Name (required) and set Can Create System Based Request (Yes/No). The user list offers only people who aren't already stewards for this object.
Removing a steward — click the delete icon on their row.
9. Putting It Together
Setting up data collection for a new object follows a natural order. Here's the typical path from start to finish:
- Add the data collection — turn it on for the domain object (section 4).
- Build the Request Model — define the table settings and the columns a request collects, then Activate it (section 5).
- Create templates — add one or more templates on top of the model, and set up their layout and mapping (section 6).
- Set up user groups — create the groups who can raise requests, add their users, and assign the templates each group may use (section 7).
- Add data stewards — name the people who'll process the requests, and decide who can create system-based ones (section 8).
Once all five are in place, requesters can raise requests in Material Request and stewards can handle them in Material Steward.
THE ORDER MATTERS — Each step builds on the one before: templates need an activated model, groups assign those templates, and stewards process what the groups' users submit. Working top to bottom avoids doubling back.
10. Quick Reference
A fast lookup for the most common actions.
| I want to… | Do this |
|---|---|
| Open Data Collection | Governance → Configuration → Data Collection |
| Turn on data collection for an object | Click the + button → Select an Object → Save & Close |
| Open one of an object's four areas | Click its card (Manage Templates, Request Model, User Groups, Data Steward) |
| Go back to the landing page | Click Back To Config |
| Define the fields a request collects | Request Model → add columns |
| Make a Request Model live | Fill in all required settings → click Activate |
| Add a template | Manage Templates → + button → fill in Add New Template |
| Edit a template's layout and mapping | Manage Templates → click the Edit icon |
| Let a group raise requests | User Groups → set Can Create Request = Yes |
| Add people to a group | User Groups → Edit → List of Users → Add User |
| Choose which templates a group can use | User Groups → Edit → Templates → Add |
| Add someone who processes requests | Data Steward → + button → choose the user |
| Allow a steward to create system-based requests | Data Steward → set Can Create System Based Request = Yes |
Source: OnCoor Governance product documentation, written for end users. For the latest screens and options, always refer to the in-app interface.